本帖最后由 cherfz 于 2022-3-18 09:27 编辑
2022.3.18补充信息:按下面3月14日的设置完之后,仍然存在dlna不响应的情况,没有办法。只好双重手段,再增加设备定时重启minidlna服务,在计划任务里面使用下述命令:
/etc/init.d/minidlna restart
为了定时执行重启命令,使用crontab执行时间,大家可以使用下面网站工具思考定时的格式和验证自己格式执行预期。crontab执行时间计算 - 在线工具 (tool.lu)
最后,我设置好的是这样的。第一行是minidlna的,*/8表示每8小时重启一次。第二行是nfs共享文件夹服务,每天6点59重启一次。第三行是docker里面的emby服务,也经常掉线,设定三小时重启一次。特别提醒,minidlna和emby的重启都不影响客户端正在播放的视频,但是emby重启时会导致APP管理界面或者web管理页面掉线。
-------------------------------------------分割线
2022.3.14我为了共享硬盘下载的视频到播放器,曾经挂电脑开启smb。这段时间陆续尝试N1(openwrt,f大69+o)开启smb(58mbps),nfs(78mbps),上周开启minidlna,哇(200+mbps)!!
谁成想,好景不长,里面的文件下载了新视频,总是不刷新,最后所有文件都无法读取。今天上网查了不少资料。最有价值的2篇,包括(如果不让外联,请版主提醒我改):
1.
dlna - Why is the minidlna database not being refreshed? - Stack Overflow
这篇文章是2011年的,真是年代久远,陆续有人补充。那时候minidlna还不完善。帖子里面提出了几种解决方案。比如设置计划任务(*/5 * * * *, 参数)重启restart(参数-R)minidlna,还有是重置reload(参数-r)minidlna的数据文件。还讨论了打开inotify命令,也讨论了用notify(注意,和inotify不是一个命令,首字母差一个i)设定每分钟或者几分钟刷新数据库。你别说,这些都能解决问题。最后2017年[color=var(--theme-link-color)]der Michi到,他研究发现minidlna刷新问题是inotify命令参数max_user_watches设定数值偏小,需要设定更高上限,满足minidlna刷新数据的要求。
英文原版
汉化版本
对这个参数的讨论就涉及另一个链接,感兴趣可以看看。部分摘抄如下
2.
安装inotify-tools,用inotifywait命令监听文件或目录的访问信息_honey,honey,honey!-CSDN博客
inotify定义了下列的接口参数,可以用来限制inotify消耗kernel memory的大小。由于这些参数都是内存参数,因此,可以根据应用需求,实时的调节其大小:
/proc/sys/fs/inotify/max_queued_evnets表示调用inotify_init时分配给inotify instance中可排队的event的数目的最大值,超出这个值的事件被丢弃,但会触发IN_Q_OVERFLOW事件。
/proc/sys/fs/inotify/max_user_instances表示每一个real user ID可创建的inotify instatnces的数量上限。
/proc/sys/fs/inotify/max_user_watches表示每个inotify instatnces可监控的最大目录数量。如果监控的文件数目巨大,需要根据情况,适当增加此值的大小。
基于上述两个帖子,得到解决方案:
用WinSCP到/etc/sysctl.d下,编辑“30-minidlna.conf”文件,修改最大监测数值成524288:
fs.inotify.max_user_watches=524288
来恩山论坛十几年了,都是拜读大佬的帖子思考。今天解决自己问题过程中学到的一些方法,和大家分享,希望能帮助碰到一样问题的人。